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We present PolySing(J, a calculus that models process interaction based on copyless message passing, 
in the style of Singularity OS. We equip the calculus with a type system that accommodates polymor- 
phic endpoint types, which are a variant of polymorphic session types, and we show that well-typed 
processes are free from faults, leaks, and communication errors. The type system is essentially linear, 
although linearity alone may leave room for scenarios where well-typed processes leak memory. We 
identify a condition on endpoint types that prevents these leaks from occurring. 

1 Introduction 

Singularity OS is the prototype of a dependable operating system where processes share the same address 
space and interact with each other solely by message passing over asynchronous channels. The overhead 
of communication-based interactions is tamed by copyless message passing: only pointers to messages 
ai"e physically transferred from one process to another. Static analysis of Singularity processes guarantees 
process isolation, namely that every process can only access memory it owns exclusively. 

In 121 we presented CoreSingj^, a formalization of the core features of Singji - the language used 
for the implementation of Singularity OS - along with a type system ensuring that well-typed processes 
are free from communication errors, memory faults, and memory leaks. At first sight it might seem 
that these properties can be trivially enforced through a linear type system based on session types lITOl 
[Tn . However, in 111 we remarked how linearity alone can be too restrictive in some contexts and too 
permissive in others. To illustrate why linearity can be too restrictive, consider the code fragment 

expose (a) { send(b, arg, *a) ; *a := new T(); } 

which dereferences the pointer a and sends *a on the endpoint b. Linearity is violated right after the 
send (arg, b, *a) command, since *a is owned both by the sender (indirectly, through a) as well as 
by the receiver. The construct expose is used by the Singfj compiler to keep track of memory ownership. 
In particular, Singjj allows pointer dereferentiation only within expose blocks. The semantics of an 
expose (a) block is to temporarily transfer the ownership of *a from a to the process exposing the 
pointer. If the process still owns *a at the end of the expose block, the construct is well typed. In lH we 
showed that all we need to capture the static semantics of expose (a) blocks is to distinguish cells with 
type *t (whose content, of type t, is owned by the cell) from cells with type *• (whose content is owned 
directly by the process). At the beginning of the expose block, a is accessed and its type turns from *t 
to *•; within the block it is possible to (linearly) use *a; at the end of the block, *a is assigned with the 
pointer to a newly allocated object that the process owns, thus turning a's type from *• back to some *s. 
An example where linearity can be too permissive is given by the code fragment 

(e, f) := openO; send(e, arg, f ) ; close(e); (1) 

which creates the two endpoints e and f of a channel, sends f as the argument of an arg-tagged message 
on e, and closes e. This code uses e and f linearly and is well typed by associating e and f with suitable 
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endpoint types T and S, where T = !arg(S).end and S = jJ. a. 7 a.rg{a). end. Observe that the code 
fragment ([T]) uses e in accordance with type T and that T and S are dual endpoint types (they describe 
complementary actions). Yet, the code generates a memory leak: after the close instruction, no reference 
to f is available, therefore the arg-tagged message will never be received and f will never be deallocated. 
In 121 we have shown that the leak produced by this code originates from the recursive type S and can 
be avoided by imposing a simple restriction on endpoint types. The idea is to define a notion of weight 
for endpoint types which roughly gives the "depth" of the message queues in the endpoints having those 
types and to restrict endpoint types to those having finite weight. Then, one can show that the code ([U is 
well typed only if endpoint types with infinite weight are allowed. 

In this work we present PolySingfj, a variant of CoreSingtJ where we add bounded polymorphism to 
endpoint types, along the lines of ||8l, while preserving all the properties mentioned earlier. For instance, 
the polymorphic endpoint type !ni(05)(a).?m(a).end denotes an endpoint on which it is possible to send 
an m-tagged message with an argument of any type, and then receive another m-tagged message whose 
argument has the same type as that of the first message. It is possible to specify bounds for type variables, 
like in !ni(a ^ ?)(a).?m(a).end, to denote that the type variable a ranges over any subtype of t, and to 
recover unconstrained polymorphism by devising a type Top that is supertype of any other type. 

Now, it may come as a surprise that, when polymorphic endpoint types are allowed, the code frag- 
ment ([T]) can be declared well typed without resorting to recursive types by taking T = !arg(a)(a).end 
and S = ?arg(a)(a).end. Since the type T of e is polymorphic, e accepts a message with an argument 
of any type and, in particular, a message with argument f . Fortunately, a smooth extension of the finite- 
weight restriction we have introduced in the monomorphic case rules out this problematic example. The 
idea is to estimate the weight of type variables by looking at their bound. In T and S above, the type 
variable a has no bound (or, to be precise, is bounded by the top type Top) and therefore is given infinite 
weight. When a occurs in a constraint a ^ f, we estimate the weight of a to be the same as the weight 
of t. The estimation relies on a fundamental relationship between weights and subtyping, whereby the 
weight of s is always smaller than or equal to the weight of f if ^ We show that forbidding the output 
of messages whose argument has a type with infinite weight allows us to prove the absence of leaks, 
together with the other desired properties. Our work is the first to formalize polymorphic endpoint types, 
which are effectively described as a feature of Singularity contracts |[T3l even though, to the best of our 
knowledge, they never made it to the prototype implementation of Singularity. Also, the availability of 
polymorphic endpoint types allows us to encode linear mutable cells. This renders the *t and *• types 
superfluous and makes our model even more essential with respect to the one presented in 121. 

The rest of the paper is organized thus: Section|2]presents an example to introduce all the fundamental 
concepts (endpoint types, subtyping, bounded polymorphism) of this work; in Section [3] we define the 
syntax and operational semantics of PolySingji and we formalize the notion of well-behaved process as a 
process where faults, leaks, and communication enors do not occur; Section|4]defines the type system for 
PolySingjJ and presents a soundness result (well-typed processes are well behaved). We discuss related 
work in Section |5] and we draw some conclusions in Section [6l Proofs and additional technical material 
can be found in the long version, which is available at the authors' home pages. 

2 An example 

It has already been observed in the recent literature that session types can conveniently describe the 
interface of distributed objects. For instance, the session type 

SellerT = /ia.(!of f er(nat).?response(nat).a © !buy(string).end © !leave().end) 
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may be used to describe (part of) the behavior of a Seller object as it can be used by Buyer. Buyer may 
make an offer regarding an item he or she is interested to buy by sending a of f er message and receiving 
a counteroffer from Seller. After this exchange of messages, the protocol repeats itself. Alternatively, 
Buyer may buy the item by sending a message that contains the delivery address, or it may leave the 
virtual shop. Buyer and Seller are connected by a pair {c,d) of related endpoints: c : Seller! is given 
to Buyer which can use it according to the protocol Seller!; d : Seller! is used by Seller and its 
type Seller! is the dual of Seller!, where inputs have been replaced by outputs and vice versa. This 
guai^antees that Buyer and Seller interact without enws. 

Suppose now that we want to implement a Broker to which Buyer can delegate the bargaining proto- 
col with Seller. We may describe Broker in some pseudo-language, as follows: 

1 BROKER (Z? : Broker!) { 

2 Po '■= receive price); 

3 X := receive (Zj, seller); 

4 p := po; 

5 while (better_deal(7?o ) Z') ) "C 

6 send(:ic, offer, compute_new_of f er(/?o > p)) ', 

7 P '■- receive (a;, response); 

8 } 

9 send(b, price, p) ; 

10 send(Zj, seller, x) ; 

11 } 

Buyer and Broker interact by means of another pair {a,b) of related endpoints, a : Broker! in use by 
Buyer (not shown here) and b : Broker! in use by Broker. Broker accepts an initial price po and the 
endpoint of Seller from Buyer (lines 2-3). Then, it engages the bargaining protocol with Seller (lines 
4—8) until the best deal p is achieved. Finally, it returns p and the Seller's endpoint to Buyer (lines 9-10) 
so that Buyer can conclude the interaction with Seller appropriately. 

Buyer interacts with Broker on the endpoint a, whose type can be described by: 

Broker! = !pr ice(nat).! seller (Seller!). ?price(nat).?seller (Seller!). end 

Observe that Broker! might be considered too precise, since Broker uses only a strict subset of the 
functionalities supported by Seller and described in Seller!. To maximize reusability, it could be more 
appropriate to replace the type Seller! in Broker! with 

Bargain! = /ia.!of f er(nat).?response(nat).a 

which specifies the minimum set of functionalities of Seller that Broker actually uses. Buyer can still 
delegate an endpoint of type Seller! to Broker since Seller! is a subtype of Bargain!, which we 
express as the relation Seller! ^ Bargain!. This is consistent with the notion of subtyping in object- 
oriented languages: if we think of the message tags in Seller! as of the methods provided by Seller, 
then Bargain! is one possible interface that Seller implements and in fact is the least interface needed 
by Broker. The problem, in this case, is that when an endpoint is delegated. Buyer can no longer use it 
(endpoints are linear resources). It is true that Broker eventually returns Seller's endpoint to Buyer, but 
by that time its type has been widened to Bargain! and Buyer can no longer access the functionalities 
in Seller! that have been hidden in Bargain!. This lost information can be recovered using bounded 
polymorphism and by giving a more precise type to a: 

Broker! = !price(nat).!seller(a ^ Bargain!)(a).?price(nat).?seller(a).end 
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Table 1: Syntax of PolySingd processes and of heap objects. 



P ::= 


Process 


At ::= 


Heap 





(idle) 





(empty) 


X 


(variable) 


1 a !->■ [a,q] 


(endpoint) 




V^V-'HJSC V-'llClllllCi^ 


1 III! 


( cw<^\1^\^\^^t^ c\x\\ 


open{a,a).P 


(open channel) 






u\m{u).P 


(send) 


q ::= 


Queue 


1 ^;g/M?m,(;c,-)-P( 


(receive) 




(empty) 


1 P®P 


(choice) 


ni(a) 


(message) 


P\P 


(composition) 


1 <?"<? 


(composition) 


recX.P 


(recursion) 







In this case, the protocol still allows Buyer to send any endpoint con^esponding to Seller whose 
type conforms to (is a subtype of) Bargain!, but it also specifies that the endpoint eventually returned 
to Buyer has the same type as the one sent earlier. In general, once an endpoint has been delegated, 
the delegator loses access to the endpoint as well as to any information about its type. This loss of 
information, which alone justifies the interest for bounded polymorphism in sequential programming, is 
likely to occur much more frequently in our context where many resources are linear. 

3 Language syntax and semantics 

We fix some notation: we use P, Q, ... to range over processes and a, b, ... to range over heap pointers 
(or simply pointers) taken from some infinite set Pointers; we use x, y, ... to range over variables 
taken from some infinite set Variables disjoint from Pointers and we let u,v,... range over names, 
which are elements of Pointers U Variables; finally, we let X range over process variables. 

The language of processes, defined by the grammar in Table [H essentially is a monadic pi-calculus 
equipped with tag-based message dispatching and primitives for handling endpoints. The process is 
idle and performs no action. Terms rec X .P and X are used for building recursive processes, as usual. The 
process u\m{v).P sends a message m(v) on the endpoint u and continues as P. A message is made of a tag 
m along with it parameter v. The term Y,iei^'^^i{^i)-Pi denotes a process that waits for a message from 
the endpoint u. The tag m, of the received message determines the continuation P,- where the variable 
Xi is instantiated with the parameter of the message. We assume that in every such term the m,'s are 

pairwise distinct. Sometimes we will write u7mi{xi).Pi H \- u7m„{x„) .P„ in place of Y!i=i u7mi{xi).Pi. 

The term open(fl',Z7).P denotes a process creating a channel, represented as two peer endpoints a and b. 
The process close(M) closes the endpoint located at u. The processes P®Q and P | 2 are standard and 
respectively denote the non-deterministic choice and the parallel composition of P and Q. The sets of 
free and bound names of every process P, respectively denoted by fn(P) and bn(P), ai^e standard: the 
construct open{a,b).P binds both a and b in P, while Y^iei^'^^ii^d-^i binds x,- in Pi for each / € /. The 
construct rec X is the only binder for process variables. We adopt the Barendregt convention for both 
variables and process variables. 

Example 3.1 (linear mutable cell). The following process models a linear mutable cell located at c: 



CELL(c) = recX.(c?set(x).c!get(x).X + c?free().close(c)) 
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Table 2: Reduction of systems. 



(R-Open) 




(R-Rec) 


{lJ.;open{a,b).P) 


{lJ.,a i-> [b,e],l 


7^[a,e];P) {n;recX.P)^ {n;P{recX.P/X}) 


(R-Choice) 


(R-Send) 




{^■,P(BQ)^{^i;P) 


{H,a ^ [b,q],b 


iH> [a,q'];a\m{c).P) {pL,a^ \b-,q]-,b i-> [a,q' :: iii(c)];P) 


(R-Receive) 




(R-Par) 




kei 


(Ai;P) ^ (At';/") 


(/I, a ^ [b,mk{c) :: q]-Xieia'^'^i{xi).Pi) 


(/i,a ^ [b,q\,Pk{c/xu}) in;P 1 Q) ^ in';P' \ Q) 


The user of the cell interacts with it on 


the peer endpoint of c. Initially, the cell is empty and offers 



to its user the possibility of setting (with a set-tagged message) the content of the cell with a pointer 
X, or deallocating (with a free-tagged message) the cell. In the first case, the cell transits into a new 
state where the only possible operation is retrieving (with a get-tagged message) the content of the cell. 
At that point, the cell returns to its original state. The cell is linear in the sense that it allows setting 
its content only if the previous content has been retrieved. This cell implementation resembles that of a 
I -place buffer, but we retain the name "cell" for continuity with our previous work ■ 

Heaps, ranged over by jj., are finite maps from pointers to heap objects represented as terms 
defined according to the syntax in Table [T] the heap is empty; the heap a i-> [b,q] is made of an 
endpoint located at a which is a structure referring to the peer endpoint b and containing a queue q of 
messages waiting to be read from a. Heap compositions At,/i' are defined only when the domains of the 
heaps being composed, which we denote by dom(Ai) and dom(/i'), are disjoint. We assume that heaps 
are equal up to commutativity and associativity of composition and that is neutral for composition. 
Queues, ranged over by ^, . . . , are finite ordered sequences of messages mi (ci )::••• :: m„(c„). We build 
queues from the empty queue e and concatenation of messages by means of ::. We assume that queues 
are equal up to associativity of :: and that e is neutral for ::. 

We define the operational semantics of processes as the combination of a structural congruence rela- 
tion and a reduction relation. Structural congruence, denoted by =, is the least congruence relation that 
includes alpha conversion on bound names and the usual laws 

P\0 = P P\Q = Q\P P\{Q\R) = {P\Q)\R 

PolySingjj processes communicate with each other by means of the heap. Therefore, the reduction 
relation defines the transitions of systems instead of processes, where a system is a pair (/x;P) of a heap 
jj. and a process P. The reduction relation — inductively defined in Table|2l is described in the following 
paragraph. (R-Open) creates a new channel consisting of two fresh endpoints which refer to each other 
and have an empty queue. (R-Choice) (and its symmetric, omitted) states that a process P (BQ may 
autonomously reduce to either P or Q leaving the heap unchanged. (R-Send) describes the output of a 
message m{c) on the endpoint a. The message is enqueued at the right end of a's peer endpoint queue. 
(R-Receive) describes the input of a message from the endpoint a. The message at the left end of 
fl's queue is removed from the queue, its tag is used for selecting some branch k ^ I, and its parameter 
instantiates the variable x^. (R-Par) (and its symmetric, omitted) expresses reductions under parallel 
composition. The heap is treated globally, even when it is only a sub-process to reduce. (R-Rec) is the 
usual unfolding of recursive processes. Observe that the Barendregt convention makes sure that in the 
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unfolding P{rec X.P/X} of a recursive process no name occurring free in P is accidentally captured, 
because fn(P) n bn{P) = 0. Not shown in Table|2]is the usual rule (R-Struct) describing reductions 
modulo structural congruence, which plays an essential role in ensuring that open{a,b).P is never stuck, 
because a and b can always be alpha converted to some pointers not occurring in dom(/x). There is 
no reduction for close (a) processes. In principle, close (t?) should deallocate the endpoint located at 
a by removing its association from the heap. However, since peer endpoints mutually refer to each 
other, removing one endpoint could leave a dangling reference from the con^esponding peer. Also, it is 
convenient to treat close(a) processes as persistent because, in this way, we keep track of the pointers 
that have been properly deallocated. We will see that this information is crucial in the definition of 
well-behaved processes (Definition 13.21 ). A process willing to deallocate a pointer a and to continue as 
P afterwards can be modelled as close(<3) | P. In the following we write for the reflexive, transitive 
closure of — ^ and we write (/i;P) if there exist no /i' and P' such that {lJ.;P) — ^ {jx'\P'). 

In this work we characterize well-behaved systems as those that are free from faults, leaks, and 
communication eiTors: & fault is an attempt to use a pointer not coiTcsponding to an allocated object or 
to use a pointer in some way which is not allowed by the object it refers to; a leak is a region of the 
heap that some process allocates and that becomes unreachable because no reference to it is directly or 
indirectly available to the processes in the system; a communication error occurs if some process receives 
a message of unexpected type. We conclude this section formalizing these properties. To do so, we need 
to define the reachability of a heap object with respect to a set of root pointers. Intuitively, a process P 
may directly reach any object located at some pointer in the set f n (P) (we can think of the pointers in 
fn(P) as of the local variables of the process stored in its stack); from these pointers, the process may 
reach other heap objects by reading messages from other endpoints it can reach. 

Definition 3.1 (reachable pointers). We say that c is reachable /rom a in jj., notation c a, if a i-> [b,q :: 
m(c) q'] € We write c ~<*^ a for the reflexive, transitive closure of . Let reach (A, jU) = {c \3a £ 
A : c ^* a}. 

We now define well-behaved systems formally. 

Definition 3.2 (well-behaved process). We say that P is well behaved if (0;P) (jU; Q) implies: 

1. dom(/x) = reach(fn(Q),jU); 

2. Q = P\\P2 implies reach(fn(Pi),/i) n reach(fn(P2),M) = 0; 

3. Q=P\\P2 and (jU ; A ) where Pi does not have unguarded parallel compositions imply either 
Pi =0 or Pi = close(a) or Pi = Y,ieiCi'^^i{xi).Pi and a ^ [b, e] € /i. 

In words, a process P is well behaved if every residual of P reachable from a configuration where the 
heap is empty satisfies a number of conditions. Conditions (1) and (2) guarantee the absence of faults 
and leaks. Indeed, condition (1) states that every pointer to the heap is reachable by one process, and 
that every reachable pointer corresponds to an object allocated on the heap. Condition (2) states that 
processes are isolated, namely that the sets of reachable pointers corresponding to different processes are 
disjoint. Since processes of the form close (a) are persistent, this also guarantees the absence of faults 
where a process tries to use an endpoint that has already been deallocated, or where the same endpoint is 
deallocated twice. Condition (3) guarantees the absence of communication eiTors, namely that if (/i ; Q) 
is stuck (no reduction is possible), then it is because every non-terminated process in Q is waiting for a 
message on an endpoint having an empty queue. This configuration corresponds to a genuine deadlock 
where every process in some set is waiting for a message that is to be sent by another process in the same 
set. We only consider initial configurations with an empty heap for two reasons: first, we take the point 
of view that initially there are no allocated objects; second, since we will need a well-typed predicate for 
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Table 3: Syntax of types. 



T 



end 



Endpoint Type 

(termination) 



t 



Type 

Top (top type) 

T (endpoint type) 



a 



(variable) 



l{mi{ai^ti){si).Ti}iei 
7{mi{ai^ti){si).Ti}ia 



(internal choice) 
(external choice) 
(recursive type) 



heaps and we do not want to verify heap well-typedness at runtime, we will make sure that the empty 
heap is trivially well typed. 

4 Type system 

We introduce some notation for the type system: we assume an infinite set of type variables ranged 

over by a, /3, Types are ranged over by t, s, ... while endpoint types ai^e ranged over by T, 5, 

The syntax of types and endpoint types is defined in Table [3] An endpoint type describes the behavior 
of a process with respect to a particular endpoint. The process may send messages over the endpoint, 
receive messages from the endpoint, and deallocate the endpoint. The endpoint type end denotes an 
endpoint on which no further input/output operation is possible and that can be deallocated. An endpoint 
type !{m;(a,- ^ tj){si).Ti}i^i denotes an endpoint on which a process may send any message m,- with 
/ G /. The message cames an argument of type Si and the type variable a,- can be instantiated with any 
subtype of the bound tj (subtyping will be defined shortly). Depending on the tag m, of the message, the 
endpoint can be used thereafter according to the endpoint type 7]. In a dual manner, an endpoint type 
?{m,(a,- ^ ti){si).Ti}j^i denotes and endpoint from which a process must be ready to receive any message 
m,- with / G I. Again, Si denotes the type of the message's argument, while ?, is the bound for the type 
variable a,. Depending on the tag m, of the received message, the endpoint is to be used according to 7]. 
Terms a and na.T can be used to specify recursive behaviors, as usual. Types are either endpoint types 
or the top type Top, which is supertype of any other (endpoint) type. 
Here are some handy conventions regarding types and endpoint types: 

• we sometimes use an infix notation for internal and external choices and write !mi {ai ^t\){si).Ti(B 
••• e !m„(a„ ^ tn){sn).T„ instead of !{m,(a,- ^ ?i)(^,-)-^-}re{i,...,4 and ?mi(ai ^ ti){si).Ti H h 

instead of ?{iii;(o:,- ^ f;)(5r)-^}ie{i,. ..,«}; 

• we omit the bound when it is Top and write, for example, \m{a){s).T in place of !m(a ^ Top)(5).r; 

• we omit the bound specification (•) altogether when useless (if the type variable occurs nowhere 
else) and write, for example, !m(5).r; 

• we omit the type of the argument when irrelevant. 

We have standai^d notions of free and bound type variables for (endpoint) types. The only binders are 
jX and the bound constraints for messages. In particular, pLa.T binds a in T and tni(o; ^ t){s).T where 
t G {!, ?} binds a in 5 and in T but not in t. We adopt the Barendregt convention for type variables. In 
what follows we will consider endpoint types modulo renaming of bound variables and folding/unfolding 
of recursions, that is pLa.T = T{iia.T / a} where T {pLa.T / a} is the endpoint type obtained from T by 
replacing each free occurrence of a with p,a.T . 
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The duality between inputs and outputs induces dual bounding modalities. In particular, a process 
using an endpoint with type !m(a ^ t){s).T may choose a particular ^ ? to instantiate a and use 
T{t' /a} accordingly. In other words, the variable a is universally quantified over all the subtypes of t. 
Dually, a process using an endpoint with type ?ni(a ^ t){s).T does not know the exact type ^ ? with 
which a is instantiated, since this type is chosen by the sender. In other words, the type variables of an 
external choice are existentially quantified over all the subtypes of the corresponding bounds. 

Not every term generated by the grammar in Table [3] makes sense. Type variables bound by a recur- 
sion jU must be guarded by a prefix (therefore a non-contractive endpoint type such as a. a is forbidden) 
and type variables bound in a constraint as in !m(a ^ t){s).T can only occur in s and within the prefixes 
of T. We formalize this last requirement as a well-formedness condition for types denoted by a judgment 
<y , h f where ^ is a set of so-called inner variables (those that can occur only within prefixes) and iff 
is a set of so-called outer variables (those that can occur everywhere): 

y,ffhend y,ffhTop — — — 

tG{!,?} 0,J^U^hf; ('^^^ 0,^U(^U{a;}h5,- j^U{a,-},^h7;-('^') 

J^,ffh-\{mi{aii^ti){si).Ti}iei 

We say that t is well formed if 0,0 h f is derivable. Observe that well-formed (endpoint) types are 
closed. Well formedness restricts the expressiveness of types, in particular types such as !m(a ^ t){s).a 
and ?m(a ^ t){s).a are forbidden because ill formed. We claim that ill-formed types have negligible 
practical utility: a process that instantiates a with 5 ^ T in lm{a ^ T){s).a precisely knows its behavior 
after the output operation; dually, a process that receives a message from an endpoint with type ?m(a ^ 
T){s).a cannot do any better than assuming that a has been instantiated with T. 

Duality expresses the fact that two processes accessing peer endpoints interact without eiTors if they 
behave in complementary ways: if one of the two processes sends a message, the other process waits for 
a message; if one process waits for a message, the other process sends; if one process has finished using 
an endpoint, the other process has finished too. 

Definition 4.1 (duality). We say that S! is a duality relation if {T,S) G implies either 

• T = S = end, or 

• T = ?{m,-(a,- ^ ti){si).Ti}iei and S = !{m,-(aj ^ ti){si).Si}iei and (7]-,5,) G &for every i G /, 

• T = !{m,-(a; ^ ti){si).Ti}i^j and S = ?{m,-(a; ^ ti){si).Si}iei and (7;-,S,) S ^for every i G /. 
We say that T and S are dual if{T,S) € Si for some duality relation 3>. 

It is easy to see that if T and 5i are dual and T and 52 are dual, then = ^2. In other words, the 
duality relation induces a function ~ such that T and T are dual for every T . 

An important property of well-formed endpoint types is that duality does not affect their inner vari- 
ables. Therefore, duality and the instantiation of inner variables commute, in the following sense: 
Proposition 4.1. Let {a},0 h T. Then Y{sja\ = T{sla\. 

We now define subtyping. Because of bound constraints on type variables, subtyping is relative to 
an environment A = tti ^ fi , . . . , a„ ^ f„ which is an ordered sequence of constraints such that each a,- 
may only occur in the ?y's with j > /. We write dom(A) for the domain of A and A(a,) to denote the 
bound ti associated with the rightmost occurrence of a, € dom(A); we use • to denote the empty bound 
environment. Subtyping is fairly standard, therefore we provide only a coinductive characterization (an 
equivalent deduction system restricted to finite endpoint types can be found in ISl). 
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Definition 4.2 (subtyping). We say that y is a coinductive subtyping if {A,t,s) G y implies either: 

1. t = s, or 

2. s = Top, or 

3. t = ae dom(A) and {A,A{a),s) G y, or 

4. t = ?{ni/(a,- ^ ti){sj).Tj}ia and s = ?{in;(a,- ^ ti){s'i).Si}iej with I <ZJ and ((A, a,- ^ ti),Si,s'i) G y 
and ((A, a,- ^ f,), T]-,^,) G y for every i G /, or 

5. t = !{m, (a; =^ ti){si).Ti}i^j and s = !{ni,(a,- ^ ti){s'i).Si}iej with J Q I and ((A,a; ^ ti),s'.,Si) G y 
and ((A, a,- < f,), T]-,^,) G y for every i G /. 

We write A\- t ^s if{A,t,s) G y for some coinductive subtyping y and t ^s if* \- t ^s. 

Item (1) states that subtyping is reflexive; item (2) states that Top is indeed the top type; items (4) 
and (5) are the usual covariant and contravariant rules for inputs and outputs respectively. Observe that 
subtyping is always covariant with respect to the continuations and that we require the bounds on type 
variables of related endpoint types be the same. This corresponds to the so-called "Kernel" variant of 
bounded polymorphism as opposed to the "Full" one. We adopt the Kernel variant for simplicity, since 
it is orthogonal to the rest of the theory. Also, the Full variant is known to be undecidable IHl. Finally, 
item (3) allows one to deduce Aha^^ifAh A(a) ^ s holds. 

The reader may easily verify that subtyping is transitive (it is enough to show that {(A,?i,f2) | 3^' : 
Ahfi ^5'&AI-s^f2}isa coinductive subtyping). The following property is standai^d and shows that 
duality is contravariant with respect to subtyping. 

Proposition 4.2. T ^ S if and only ifS^^T. 

Well-formedness of endpoint types is essential for Proposition |4.2| to hold in our setting. Consider, for 
example, the endpoint types T = \m{a ^ ?m().end)().a and S = \m{a ^ ?ni().end)().?m().end where T 
is ill formed. Then T^S would hold but ?m(a ^ ?m() .end) () . !m() .end = 5 T = ?m(a ^ ?m() .end) () .a 
would not because a ^ ?m().end h !m().end ^ a. An alternative theory where well-formedness is not 
necessary for proving Proposition |4.2| is given in [81 and consists in distinguishing dualized type variables 
a from type variables and by having type constraints of the form ti ^ a ^ t2 with both lower and 
upper bounds, so that the bounds of the con^esponding dualized type variable are known and given by 
ti^a^tl. 

Typing the lieap. The heap plays a primary role in our setting because inter-process communication 
utterly relies on heap-allocated structures; also, most properties of well-behaved processes are direct con- 
sequences of related properties of the heap. Therefore, just as we will check well typedness of a process 
P with respect to some environment that associates the pointers occurring in P with the con^esponding 
types, we will also need to check that the heap is consistent with respect to the same environment. This 
leads to a notion of well-typed heap that we develop in this section. The mere fact that we have this 
notion does not mean that we need to type-check the heap at runtime. Well typedness of the heap will be 
a consequence of well typedness of processes, and the empty heap will be trivially well typed. We will 
express well-typedness of a heap /i with respect to a pair ro;r of environments where F represents the 
type of the roots of /i (the pointers that are not referenced by any other structure allocated in the heap) 
and To describes the type of the pointers to allocated structures that are directly or indirectly reachable 
from one of the roots of the heap. 

Among the properties that a well-typed heap must enjoy is the complementarity between the endpoint 
types associated with peer endpoints. This notion of complementarity does not coincide with duality 
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because of the communication model that we have adopted, which is asynchronous. Since messages can 
accumulate in the queue of an endpoint before they are received, the type of the endpoint as perceived by 
the process using it and the actual type of the endpoint as assumed by the process using its peer can be 
misaligned. On the one hand, we want to enforce the invariant that the endpoint types of peer endpoints 
are (and remain) dual, modulo the subtyping relation. On the other hand, this can only happen when 
the two endpoints have empty queues. In general, we need to compute the actual endpoint type of an 
endpoint taking into account its type as perceived by the process using it and the messages in its queue. 
This is accomplished by the tail(-,-) function below, which takes an endpoint type T and a sequence 
mi(5i) • • •m„(5„) of specifications corresponding the messages enqueued into the endpoint with type T 
and computes the residual endpoint type that assumes that all those messages have been received: 



From a technical point of view tail is a relation, since there can be several possible choices for in- 
stantiating the type variables in the endpoint type being processed. For example, we have tail(?m(a ^ 
t){a).'?m{a).end,m{s)) = ?m(f').end for every s ^t' !^t. Nonetheless we will sometimes use tail as 
a function and write tail(r,nii (^i) • • •m„,(5„)) in place of some 5 such that tail(r,mi(5i) • • •m,„(5„)) = 
S. For instance, the notation tail(r,nii(5'i) • • •m,„(5„)) ^ S' means that S ^ S' for some S such that 
tail(r,mi(i'i)---m„,(i'„)) =S. 

We now have all the notions to express the well-typedness of a heap /i with respect to a pair To; P of 
type environments. 

Definition 4.3 (well-typed heap). We write VqS \- jj. if: 

1. for every a ^ [b,q] £ H we have b i-> [a,q'] G /I and either q = £ or q' = E; 

2. for every a i— )■ [b,m\{ci) ::•••:: m„(c„)] G /i and b i— )• [a,£] we have tail(r,mi(i'i) • • •m,„(5„)) ^ S 
where a :T and b : S (zV and Ci : Si G V for / G { 1 , . . . , n}; 

3. dom(ju) = dom(ro, V) = reach(dom(r),jU); 

4. reach({a},/x) n reach ({Zj},/i) = 0/or every a,b e dom(r) with a^b. 

Condition (1) requires that in a well-typed heap every endpoint comes along with its peer and that 
at least one of the queues of peer endpoints be empty. This invariant is ensured by duality, since a well- 
typed process does not send messages on an endpoint until it has read all the pending messages from the 
corresponding queue. Condition (2) requires that the endpoint types of peer endpoints are dual, modulo 
subtyping. More precisely, for every endpoint a whose peer b has an empty queue there exists a residual 
tail(r,mi (s\)-- •m„(5„)) of its type T whose dual is a subtype of the peer's type S. Condition (3) states that 
the type environment Fq, F must specify a type for all of the allocated objects in the heap and, in addition, 
every object (located at) a in the heap must be reachable from a root b G dom(r). Since the roots will 
be distributed linearly to the processes of the system, this guarantees the absence of leaks, namely of 
allocated objects which are no longer reachable. Finally, condition (4) requires the uniqueness of the 
root for every allocated object. This guarantees process isolation, namely the fact that every allocated 
object belongs to one and only one process. 

Typing processes. We want to define a type system such that well-typed processes are well behaved 
and, in particular, such that well-typed processes do not leak memory. As we have anticipated in the 



tail(r,£) = r 



ytG/ 



t^tk s^Skitjak} tail(r^{?/o;J,mi(/i)---m„(4)) =^ 
tail(?{m,-(ai ^ fi)(5;).7;-}/e/,mi(5)nii(/i)---m„(4)) =5 
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introduction, the critical situation that we must avoid is the possibility that an endpoint is enqueued into 
its own queue, since this would cause the creation of a circular structure not owned by any process. 

The intuition behind our solution is to use some property of types to detect — and avoid — the 
configurations in which there exists some potential to create such circular structures. This property, 
which we dub weight of a type, gives an upper bound to the length of chains of pointers linking endpoints. 

Definition 4.4 (weight). We say that W is a coinductive weight bound if {A,t,n) G W implies either: 

• t = end, or 

• t = !{m,-(a,- ^ ti){si).Ti}iei, or 

• t = ae dom(A) and {A,A{a),n) G W, or 

• t = ?{m,-(a; ^ ti){si).Ti}i^i and n>0 and ((A, a,- ^ ti),Si,n - I) and ((A, a,- ^ ti),Ti,n) G W 
for every i G /. 

We write A\- t \,nif (A,f,?i) G W for some coinductive weight bound W. The weight of a type t with 
respect to A, denoted by ||f ||a. is defined by ||? ||a = min{« GlNjAhf^''^} where we let min0 = oo. We 
omit the environment A when it is empty and simply write \\t\\ instead of \\t\\,. When comparing weights, 
we extend the usual total orders < and < over natural numbers so that n < oo for every « G IN and oo < oo. 

Like other relations involving types, the relation A h ? J, ?i is parametric on an environment A spec- 
ifying the upper bound of type variables that may occur in t and expresses the fact that n is an upper 
bound for the weight of t. The weight of t is then defined as the least of its upper bounds, or oo if 
there is no such upper bound. A few weights are straightforward to compute, for example we have 
||end|| = ||!{m,(a, ^ ti){si).Ti}i(^i\\ = and ||Top|| = oo. Endpoints with type end and those in a send 
state have a null weight because their coiTcsponding queues are empty and therefore the chains of point- 
ers originating from them has zero length. In the case of Top, it does not have a finite weight since 
Top is the type of any endpoint, and in particular of any endpoint with an arbitrary weight. Only end- 
points in a receive state do have a strictly positive weight. For instance we have ||?ni(end).end|| = 1 
and ||?m(?m(end).end).end|| = 2, while ||jUa.?m(a).r||A = ||?ni(Top).r||A = The weight of type 
variables occurring in a constraint a ^ f is given by the weight of t. In particular, ||o;||o;^r = \\t\\ and 
||?m(a ^ ?)(a).end|| = 1 + ||f|| (this latter equality holds if ||f|| < oo). In a sense, the (type) bound t for 
a determines also a (weight) bound \\t\\ for a. Since the actual type with which a will be instantiated 
is not known, this approximation works well only if the relation between the weights is coherent with 
subtyping. This fundamental property does indeed hold, as stated in the following proposition. 

Proposition 4.3. t ^ s implies \\t\\ < \\s\\. 

The typing rules for processes are inductively defined in Table|4] Judgments have the form Z; A; F h P 
and state that process P is well typed under the specified environments. The additional environment Z is a 
map from process variables to pairs (A; F) and is used for typing recursive processes. It plays a role in two 
rules only, (T-Var) and (T-Rec), which are standard except for the unusual premise dom(F) = fn(P) 
in rule (T-Rec) that enforces a weak form of contractivity on recursive processes. It states that rec X.P 
is well typed under F only if P actually uses the names in dom(F). Normally, divergent processes such 
as rec X.X can be typed in every environment. If this were the case, the process open{a,b).rec X.X, 
which leaks a and b, would be well typed. The idle process is well typed in the empty environment 0. 
Since we will impose a correspondence between the free names of a process and the roots of the heap, 
this rule states that the terminated process has no leaks. Rule (T-Close) states that a process close (m) is 
well typed provided that u is the only name owned by the process and that it corresponds to an endpoint 
with type end, on which no further interaction is possible. Rule (T-Open) types the creation of a new 
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Table 4: Typing rules for processes. 



(T-Rec) 

yfata ?a'^°'''^^ . I,{X^( A;r)};A;rhP dom(r)=fn(P) 
I;A;0I-O I;A;m : end h close(M) 



I;A;rh recX.P 
(T-Open) (T-Send) 

L;A;r,a:T,b:Th P Aht'i^t \\s{t' / ajU < °° L;A;r,u : S{t' /a} h P 
I;A;r h open{a,b).P L;A;r,u : !m(a 5^ t){s).S,v : s{t'/a} h u\m{v).P 

(T-Receive) 

^^'^^^^ , L;A,ai^ti;r,u:Ti,xr.SihPi^'^'^ 
I,{X^(A;r)};A;rhX 



I;A;r,M : ?{m;(a; s: ti){si).Ti}iei h i:,e;M?m;(x,-).P,- 



(T-Choice) (T-Par) (T-Sub) 

I;A;rh/' I;A;rhe I;A;rihP I;A;r2h2 I;A;r,M:5hP Ahf^^ 

I;A;rhP©e I;A;ri,r2 hP|2 I;A;r,M :? hP 



channel, which is visible in the continuation process as two peer endpoints typed by dual endpoint types. 
Rules (T-Choice) and (T-Par) are standard. In the latter, the type environment is split into disjoint 
environments to type the processes being composed. Together with heap well-typedness, this ensures 
process isolation. Rule (T-Send) states that a process M!m(v).P is well typed if u is associated with an 
endpoint type !iii(o: ^ 0('^) '^ that permits the output of m-tagged messages. The rule guesses the type 
parameter t' with which the type variable a is instantiated (an explicitly typed process might explicitly 
provide t'). The type of the argument v must match the expected type in the endpoint type where a 
has been instantiated with t' and the continuation P must be well typed in a context where the message 
argument has disappeared and the endpoint u is typed according to a properly instantiated S. This means 
that P can rely on the knowledge of t', namely a is universally quantified over all the subtypes of t. The 
condition Hil^'/ajllA < 00 imposes that v's type must have a finite weight. Since the peer of u must 
be able to accept a message with an argument of type s{t' /a}, its weight will be strictly larger than 
that of s{t' /a}, or it will be infinite. In both cases, we are sure that the argument v being sent is not 
the peer of u. Rule (T-Receive) deals with inputs: a process waiting for a message from an endpoint 
u : ?{m;(aj ^ ti){si).Ti}i^i is well typed if it can deal with any m;-tagged message. The continuation 
process may use the endpoint u according to the endpoint type 7] and can access the message argument 
Xi. The environment V is enriched with the assumption a, ^ denoting the fact that Pi does not know 
the exact type with which a,- has been instantiated, but only its upper bound, namely a,- is existentially 
quantified over all the subtypes of Finally, rule (T-SUB) is a subsumption rule for assumptions: if a 
process P is well typed with respect to a context T,u: s, it remains well typed if the type associated with 
u is more precise than (is a subtype of) s. 

Systems (/x;P) are well typed if so are their components: 
Definition 4.5 (well-typed system). We write Hd; F h (/i;P) //Tq; F h /i and F h P. 

We conclude with two standard results about our framework: well-typedness is preserved by re- 
duction, and well-typed process are well behaved. Subject reduction is slightly non-standard, in the 
sense that types in the environment may change as the process reduces. This is common in session type 
theories, since session types are behavioral types. 
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Theorem 4.1 (subject reduction). Let Vq; V h and ;P) ^> (At';/")- Then T^; V h {n';P')for some 

Theorem 4.2 (safety). Lef h f . Then P is well behaved. 
Example 4.1. Consider the endpoint type 

CellT = /ia.(!set(j8)(/3).?get(j8).a !f ree().end) 

modeling the interface of a linear mutable cell. Then it is easy to verify that 

c : CellT H CELL(c) 

is derivable, where CELL is the process presented in Example \3.1\ Therefore, CELL is a correct imple- 
mentation of a linear mutable cell. 

Since CellT begins with an internal choice we have ||CellT|| = 0. This means that it is always 
safe to send an empty cell as the argument of a message since the second premise of rule (T-Send) 
will always be satisfied. On the contrary, we have ||?get(j8).CellT||^<j-j-op = °°> therefore it seems like 
initialized cells can never be sent as messages. However, if sender and initializer are the same process, 
there might be just enough information to deduce that the process is safe. For example, the judgment 

a:t,b: !send(?get(?). CellT). end, c : CellT h c!set(a).Z7!send(c).close(Zj) 

is derivable if \\t\\ < oo. In this case, the sub-process blseiid{c) .c\ose{b) is type checked in an environ- 
ment where the (residual) endpoint type of c has been instantiated to ?get(?). CellT whose weight is 
||?get(f).CellT|| = ||?|| + 1 <oo. ■ 

Example 4.2. Suppose we want to implement a forwarder process that receives two endpoints with dual 
types and forwards the stream of messages coming from the first endpoint to the second one. We might 
implement the process thus: 

FWD(a) =a?src(x).a?dest(j).recX.(;c?m(z).y!m(z).X+;c?eos().j!eos().(close(;c) | close (y) |close(a;))) 

However, the judgment 

a : ?src (a) (Stream) .?dest (Stream) .end h FWD(a) 

where Stream = /Ij3.(!m(a).j3 !eos().end) is not derivable because there is no upper bound to the 
weight ofoc and FWD(a) attempts at sending z where z '■ OC. Had FWD(a;) been typable, it would be possible 
to create a leak with the process 

open(<3,Z7).(FWD(<3) |open(c,(i).open(e,/).Z7!src(<i).Z7!dest(e).c!m(/).c!eos().(close(Zj) |close(c)) 

which has the effect to enqueue f into its own queue. The process FWD becomes typable as soon as a in 
a's type is given a bound with a finite weight. ■ 

5 Related work 

Copyless message passing is one of the key features adopted by the Singularity OS |[T2ll to compensate the 
overhead of communication-based interactions between isolated processes. Communication safety and 
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deadlock freedom can be ensured by checking processes against channel contracts that are deterministic, 
autonomous, and synchronizing |[T5l . As argued in fT\ and shown in ||2l, the first two conditions make 
it possible to split contracts into pairs of dual endpoint types, and to implement the static analysis along 
the lines of well known session type theories ifTOlfTTI . In lH it was also observed that these conditions 
are insufficient for preventing memory leaks and it was shown how to address the issue by imposing 
a "finite-weight" restriction to endpoint types. In the present paper, we further generalize our solution 
by allowing infinite-weight endpoint types in general, although only endpoints with finite-weight can 
actually be sent as messages (see the extra premise of rule (T-Send)). As a matter of fact, Q already 
noted that the implementation of ownership transfer posed some consistency issues if endpoints not in a 
send-state were allowed to be sent as messages, but no relation with memory leaks was observed. Since 
our "finite-weight" condition is a generalization of the send-state condition {send-state endpoints always 
have null weight), our work provides a formal proof that the send-state condition is sufficient also for 
avoiding memory leaks. Other works 17] |9l introduce apparently similar, "finite- weight" restrictions on 
session types to make sure that message queues of the coiTcsponding channels are bounded. Our weights 
are unrelated to the size of queues and concern the length of chains of pointers involving queues. 

Polymorphic contracts and endpoint types of the Singularity OS |fT3l have never been formalized 
before nor do they appear to be supported by the Singularity RDK. Our polymorphic endpoint types are 
closely related to the session types in HI, which was the first work to introduce bounded polymorphism 
for session types. There are a few technical differences between our polymorphic endpoint types and the 
session types in HI : we unify external and internal choices respectively with input and output operations, 
so as to model Singularity contracts more closely; we admit recursive endpoint types, while the support 
for recursion was only informally sketched in HI. This led us to define subtyping coinductively, rather 
than by means of an inductive deduction system. Finally, we dropped lower type bounds and preferred 
to work with a restricted language of well-formed endpoint types which we claim to be appropriate in 
practice. Another work where session types are enriched with bounded polymorphism is |6l, but in 
that case polymorphism is restricted to data, while in HI and in the present paper type variables range 
over behaviors as well. Interestingly, all the critical endpoint types in [2J that violate the "finite-weight" 
restriction ai^e recursive. This is no longer the case when (bounded) polymorphism is added and in fact 
there are finite endpoint types that can cause memory leaks if sent as messages. 

A radically different approach for the static analysis of Singularity processes is given by ifT/l [TSl . 
where the authors develop a proof system based on a variant of separation logic 1141 . However, leaks 
in ifTTl manifest themselves only when both endpoints of any channel have been closed. In particular, 
it is possible to prove that the code fragment ([T]) is correct, although it does indeed leak some memory. 
This problem has been subsequently recognized and solved in |[T6l . Roughly, the solution consists in 
forbidding the output of a message unless it is possible to prove (in the logic) that the queue that is going 
to host the message is reachable from the content of the message itself. In principle this condition is 
optimal, in the sense that it should permit every safe output. However, it relies on the knowledge of 
the identity of endpoints, that is a very precise information that is not always available. For this reason, 
|[T6l also proposes an approximation of this condition, consisting in tagging endpoints of a channel with 
distinct roles (basically, what are called importing and exporting ends in Singularity). Then, an endpoint 
can be safely sent as a message only if its role matches the one of the endpoint on which it is sent. This 
solution is incomparable to the one we advocate - restricting the output to endpoints with finite-weight 
type - suggesting that it may be possible to work out a combination of the two. 

There exist a few works on session types [Tl |4l that guarantee a global progress property for well- 
typed systems where the basic idea is to impose an order on channels to prevent circular dependencies 
that could lead to a deadlock. Not surprisingly, the critical processes (such as ^) that we rule out 
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thanks to the finite-weight restriction on the type of messages are ill typed in these works. It turns 
out that a faithful encoding of ([T]) into the models proposed in these works is impossible, because the 
open(-,-) primitive we adopt creates both endpoints of a channel within the same process, while the 
session initiation primitives in [T] |4l associate the fresh endpoints of a newly opened session to different 
processes running in parallel. This invariant - that the same process cannot own more than one endpoint 
of the same channel - is preserved in well-typed processes because of a severe restriction: whenever an 
endpoint c is received, the continuation process cannot use any endpoint other than c and the one from 
which c was received. 



6 Conclusion and future work 

In 121 we have formalized CoreSingjj, a core language of softwai^e isolated processes that communi- 
cate through copyless message passing. Well-typed processes are shown to be free from faults, leaks, 
and communication errors. In the present paper we have extended the type system of CoreSing[| with 
bounded polymorphism, on the lines on what has been done for session types in |l8l. Bounded poly- 
morphism increases the expressiveness of types and improves modularity and reusability of components. 
In our setting, where resources - and endpoints in particular- - ai^e linear, we claim that bounded poly- 
morphism is even more useful in order to avoid the loss of type information that occurs when endpoints 
are delegated and therefore exit the scope of the sender process (Section O. We have shown that the 
finite-weight restriction we introduced in [2 1 scales smoothly to the richer type language, despite the fact 
that polymorphism augments the critical situations in which a leak may occur (recursive types are no 
longer necessary to find apparently well-typed processes that leak memory, as shown in Section [Hi. This 
is mostly due to a nice property of weights (Proposition 14.31 ). Unlike 121, we have omitted cells and 
open cell types, basically because they can be encoded thanks to the increased expressiveness given by 
(bounded) polymorphism (Examples 13.11 and 14 . II ) . 

With respect to Singfj, our model still differs in a number of ways: first of all, PolySingji processes 
are terms of a process algebra, while Singfl is an imperative programming language similar to Cfl. As 
a consequence, there is no direct mapping of Sing^ programs onto PolySingJl processes, even though 
we claim that our calculus captures all of the peculiar features of Singjj, namely the explicit memory 
management (with respect to the exchange heap), the controlled ownership of memory allocated in the 
exchange heap, and the contract-based communication primitives. Second, in ||2l and in the present paper 
we do not deal with mutable record structures nor with mutable arrays but only with mutable cells. The 
extension to the general framework is straightforwai^d and does not pose new technical problems. Finally, 
the fact that we do not take into account non-Unear values is indeed a limitation of the model presented 
here, but we plan to extend it in this direction as described next. 

We envision two developments for this work. The first one is to enrich the type system with non-linear 
types, those denoting resources (such as permanent services) that can be shared among processes. Even 
though it is plausible to think that the technical details are relatively easy to work out (non-linear types 
ai^e supported by lEl and in most other session type theories) we see this enhancement as a necessary 
step for PolySingtJ to be a useful model of Singularity processes. The second development, which looks 
much more challenging, is the definition of an algorithm for deciding subtyping (Definition 14.21 ). As 
observed in lH, bounded polymorphic session types share many properties with the type language in the 
system F^- 131 . Therefore, while it is reasonable to expect that properties and algorithms for extensions 
of F<:With recursive types Q carry over to our setting, the exact details may vary. 
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